Motivation: was reminded of and read the contributing docs, which are pretty good, but the prescribe some details that don't resonate with me, so attempting to nudge the culture a bit to be less prescriptive of practices I think aren't always the best-fit practices.

NB: This touches files that the other pending PR #23 may touch, so might be wise to hold off on merging this until that merges or at least to be intentional about where to incur and resolve the likely merge conflicts.

NB: Intentionally does not update CHANGELOG and does not bump version number, figuring this changeset is meta documentation changes that don't affect the web component product as released. That's a tradeoff navigation. Local Jenkins automation might insist on trying to build and publish on merge to master anyway, which should be fine because it'll either fail or it'll succeed with a product with no functional change.

Substantive changes

• Express openness to a Pull Request as the way a contribution is communicated and discussed, not necessarily requiring additional communication in another channel where this adds more noise than signal.
• Emphasize welcoming best-efforts contributions
• Suggest GitHub's draft pull requests feature to express work-in-progress-ness

Style

Wraps Markdown files at 80 characters, updating .editorconfig to document this style.

Copy edits

Copy edits for brevity and clarity.